Nack.

1. It misses the history of edits, which many, if not all, users like
2. It makes all replies, likes and zaps disappear, which is very confusing for users, both the editors and people who have replied before: no one expects edits to erase the past post and all associated interactions with it.
3. Because it deletes the reply from view, it also breaks/forks threads. You start seeing a bunch of orphan threads because people will keep replying to replies of the deleted reply via notifications without noticing that the branch was deleted and no one will see their replies on the full thread. Lots of confusion.
4. NIP-05 Deletion is an optional relay feature and most relays and clients fail to properly implement it. Clients usually have to request deletions multiple times to get it done.

Amethyst had this delete-and-replace design for about a month back in march 2023. There were so many complaints that I decided to quickly revert it and never talk about it anymore.

I agree with Vitor, and will elaborate by saying that edit should be append-only (or switch kind 1s to be replaceable).

I believe you two haven't read my proposal. This is not "delete-and-replace", this is basically the same replace proposal from @vitorpamplona, but done with a syntax that will be interpreted by other clients as delete-and-replace, i.e. it's a way for clients that want to do the full delete thing with history and whatnot to do it while not forcing it on clients that don't want to.

Let me know if this isn't clear.

I'll address these two because they are relevant:

• Because it deletes the reply from view, it also breaks/forks threads. You start seeing a bunch of orphan threads because people will keep replying to replies of the deleted reply via notifications without noticing that the branch was deleted and no one will see their replies on the full thread. Lots of confusion.

This is a problem indeed -- again, it's a problem only for clients that do not implement the full editing functionality --, but I don't know how to solve it without forcing everybody to upgrade to an edit spec, which is what I'm trying to prevent. I think it's still preferable to have this over having the completely broken UX of edited events or the centralization that comes from the mandatory upgrade.

• NIP-05 Deletion is an optional relay feature and most relays and clients fail to properly implement it. Clients usually have to request deletions multiple times to get it done.

I get this, but I think it's better to force clients to implement honoring deletes than it is to force them to implement edits. And even if they don't implement deletes I don't think this is a problem as a big as having a mandatory edit spec around.

I just want to say that delete-and-replace already exists as two separate operations, and nostr users will delete (NIP-09 kind-5) their posts and write new posts (NIP-01) to replace them, and therefore all the problems mentioned about delete-and-replace are already happening.

I'm not super excited about this PR or indeed about any edit scheme at all, except for addressable events.

When somebody edits an event, if the replies continue to be attached, clients had better show that these replies were to an earlier version (as @jb55 commented on my proposal elsewhere) or the edit makes the replies entirely misleading. This makes nostr less simple, and I suspect there will be clients that don't get this right. That is why I liked @staab 's annotation idea since you are not editing the original at all, so replies don't become misleading.

I just want to say that delete-and-replace already exists as two separate operations

Have you read the proposal?

I just want to say that delete-and-replace already exists as two separate operations

Have you read the proposal?

Yes I read the proposal. I'm replying to Vitor who is complaining that delete-and-replace is bad. I'm telling him that we are already living in that universe.

I know that clients supporting this PR would be able to maintain associations with replies to older "pseudo-deleted" events. It still seems complicated though.

I'm telling him that we are already living in that universe.

Oh yeah, that does exist. But I don't think it is reliable at all. Most likely people will see two events in the time line because their client's cache doesn't erase events when they get deleted.

Most likely people will see two events in the time line because their client's cache doesn't erase events when they get deleted.

This would be an opportunity for them to fix that.

It's much better for clients to fix that than to introduce yet another complicated and expensive requirement for clients.

I don't understand this "complicated" and "requirement"... This PR is way more complicated than the edits one.

This PR is way more complicated than the edits one.

But it doesn't create a mandatory requirement for all the clients. That is the entire point.

I don't know if it's "way more complicated" -- I think it is a little bit more complicated, but yeah I haven't implemented either, so I don't know.

I imagine you will say your edits NIP isn't mandatory, but it creates a broken experience for everybody that isn't using it, which over time either forces all the clients to implement it or pushes everybody to move to the fewer clients that do. So it's either an extra requirement that increases implementation cost and barriers to entry and thus centralizes the network or it is a more direct push towards less clients and more centralization.

I'd rather not have the delete NIP be a requirement either, but since we already have it and there is no turning back, then it's better to reuse it in order to implement edits, so we have 1 extra requirement, not 2.

Maybe I am crazy, what is my error here?

I think I prefer the annotations NIP over this one, since it's simpler, more explicit, easier to implement and doesn't force an extra requirement either. This NIP was proposed as a less harmful alternative to those who want a "full edit" experience.

No one wants to "annotate" their post. They want to edit. Annotations don't solve the problem users are asking for.

it creates a broken experience for everybody that isn't using it,

Not implementing reactions and zaps also creates 'broken experiences" and still lots of people do use Nostr without seeing reactions and zaps. And they are all happy. It's not broken.

Clients are different and will ALWAYS show different things. What they show ALWAYS affects how you see/interpret the post. If we start labeling those things as "broken experiences" then Nostr is a huge pile of broken experiences everywhere.

This idea that if a client doesn't implement certain NIPs and doesn't show certain types of content means that the "experience is broken" is stupid. Clients will ALWAYS be different. And let them be. Users will pick what and how they want to see things.

which over time either forces all the clients to implement it or pushes everybody to move to the fewer clients that do

I am always going to side with users. If people migrate clients because of the edits, then it just proves that edits work and should be implemented by others. If users want it why would anyone fight it? It doesn't make sense.

Clients are different and will ALWAYS show different things. What they show ALWAYS affects how you see/interpret the post. If we start labeling those things as "broken experiences" then Nostr is a huge pile of broken experiences everywhere.

That's why I am not saying that these things are broken experiences! I am only saying that not displaying crucial edits is a broken experience. That is the only broken experience I can think of in all of Nostr. Not seeing likes or zaps is not a broken experience at all, I mostly use Nostr without seeing likes or zaps and I think it is ok, even better.

But if someone says "I like elephants" when in fact they wanted to say "I hate elephants" but I got the wrong message because my client didn't support edits -- that's a broken experience.

If someone writes a post and stops at the middle then later edits and finishes the post but I don't see the rest of that that's a broken experience.

If someone changes their mind completely about a topic after a while, but doesn't say that anywhere else in his feed, just edits the original post, so I never get to learn that they changed their mind that's a broken experience.

If someone makes a dynamic post that they promise they will keep updating with new information, but I know I will never get any of those updates that's a broken experience.

The current proposal fixes most of these things.

Annotations do not fix these things, but the fact that annotations are not going to be confused by users with a seamless centralized-platform edit will make them use annotations much more carefully, therefore a client that don't implement annotations won't have broken experiences most of the time. Even then annotations are much simpler to implement if you basically treat them as special comments (although you can treat them differently if you want) so that's a smaller barrier anyway.

I am always going to side with users. If people migrate clients because of the edits, then it just proves that edits work and should be implemented by others. If users want it why would anyone fight it?

This doesn't make any sense. You are already not siding with users if you are working on Nostr. Users don't want Nostr, users want TikTok. Or rather: users have no idea of what they want, they want the status quo. If they can edit posts on Twitter they will want to edit posts on Nostr. Twitter didn't have edits for 15 years and it was fine. If we show them a better way they may like it or may not like it, but you can't settle for whatever they want because that's nonsensical, if you followed that principle you would never build anything new.

Of course there is no such thing as "users". Some users are like what I described above. Others (in fact 99% of current Nostr users) want a decent decentralized protocol, and they only asking for edits because they have no idea of how much will edits cost to that decentralization part that they also want.

In any case this proposal allows you to build whatever your users want without making Nostr a shitty centralized platform in the process.

EDIT: the fact that I edit my GitHub posts is proof that people's behavior change depending on the tools you give them. If edits are seamless there will be much more edits. A lot of edits. Enough to break all assumptions on which Nostr has rested to this day.

vitor says:

No one wants to "annotate" their post. They want to edit.

I prefer to annotate my posts.

fiatjaf says:

it creates a broken experience for everybody that isn't using it,

I think it also creates a broken experience for Amethyst users. They are being lied to if they think their note has been edited. Edits that nobody else sees are not edits.

I'm actually kind of glad that we haven't been able to agree on how to do edits. Because it forced us to think up more and more different variations on how edits could be implemented. And I think we needed to have all those options in front of us to help us think through which one is the best.

EDIT: the fact that I edit my GitHub posts is proof that people's behavior change depending on the tools you give them.

No. The fact that you use edits and not annotations to fix your post makes my point. You could have just annotated. But that is not natural.

If edits are seamless there will be much more edits. A lot of edits.

Nostr already has 50,000 kind 1010 edits on the major relays. People are using it.

I think it also creates a broken experience for Amethyst users. They are being lied to if they think their note has been edited. Edits that nobody else sees are not edits.

Our users know that the edits only show up on Amethyst and they still edit. That's not a broken experience. In fact, it is one of our most loved features.

https://njump.me/nevent1qvzqqqqqqypzp3hhqal3dxw4pnuj49jjhl4lltq9l35y9w0w8yggnk2ehzk46j8aqy2hwumn8ghj7un9d3shjtnwdaehgu3wvfnj7qghwaehxw309aex2mrp0yhrq7rrdpshgtnrdakj7qg3waehxw309ahx7um5wghxcctwvshszymhwden5te0wahhgtn4w3ux7tn0dejj7qghwaehxw309ae8xumvv9ujumn0wd68ytnddajj7qpqrs5d92zrczzhjkn93ghkqt997jje39ta2zg4spz247dx7pf5rmjs22u4rq

@staab it would be the same if annotations were used. Clients that don't implement Annotations don't see the "it's fake" add-on.

Sure they do, as a reply. And no one would be surprised that their note shows different content in different clients. I offer this as a counter example to this statement:

Our users know that the edits only show up on Amethyst and they still edit. That's not a broken experience. In fact, it is one of our most loved features.

Edit: Ok, I guess Iefan likes edits.

Sure they do, as a reply. And no one would be surprised that their note shows different content in different clients.

Not in the same way that would alert everyone.. their own reply would be all the way down with everybody else's reply in majority of clients. Completely "broken experience" as you all like to say...

Completely "broken experience"

That's not broken at all. I do it all the time when I make a joke and no one understands it: I just go there and answer myself with a comment saying it was a joke. Would be better if it was a special thing appended to the original post, but it's not bad currently either.

Also if there is any client out there that puts replies from the original author at the top (like Twitter does and like what @dergigi has been asking for years because it is truly an essential feature) that is basically a non-issue already.

Amethyst does that. But you still need to click in the post to see the replies and then the annotation. Which is not what people want.

Why not display the annotations in the feed without requiring a click?

Why not display the annotations in the feed without requiring a click?

We could, but the point is that clients that don't implement it are still "broken". Many clients don't even load replies until you click on it (only the counter loads). And if they need to implement something, they can just do #1090 instead.

The problem is that with annotations people know they can't change everything, all they can do is to append some stuff.

With full-blown edits they just treat it is an actual real edit and expect everybody to see the full thing, so they will edit freely and largely, changing everything at their whim -- like the guys keeping dossiers of information and lists, for example, which are better served by other kinds anyway.

Anyway, this gives me another idea for an alternative proposal.

I think it’s most important to note here that there are many ways to implement editable notes.
In the future there may exist several parallel, incompatible implementations of editable notes on Nostr.
And as awful as that sounds, that may be useful as not all clients have the same ambitions for UX.
Also I believe a huge part of the nostrability initiative will be to bridge data formats as best as possible.

Therefore I am in clear favour of moving editable notes specifications as far out of the kind 1 specification as possible, and maybe even out of the NIPs.
IMAO it’s a matter for the client to figure out if, and how, to deal with edits, and there is nothing to hinder them trying to obtain compatibility with other clients.

But editable notes are complicated and shouldn’t be a must have.